In 3GPP (Third Generation Partnership Program), for both UMTS (Universal Mobile Telecommunication System) and GSM/EDGE (Global System for Mobile Communication/Enhanced Data rates for GSM Evolution) systems, an LCS (Location Communication System) client (i.e. a client application hosted by either a mobile station/user equipment including a mobile terminal or by a non-mobile device operated by a user who wants to know the location of a mobile station) can request an LCS server (provided by/or coupled to a corresponding operator network) to provide a position estimate to the client, either for the device hosting the client itself or for some other equipment (a mobile station). For example, a mobile station may itself ask (as an LCS client) for an estimate of its own location/position, or an application hosted by a computer linked to the Internet and ultimately to an LCS server, may send a request to the LCS server for an estimate of the location/position of a mobile station (a request that would be honored usually only if the user of the application has been authorized to receive such information). In either case, the location/position estimate to be provided is an estimate of the position of a mobile station communicatively coupled to an operator network via a radio access network (RAN), which in turn includes or is coupled to the LCS server.
One way for an LCS server to provide a location estimate for (i.e. to provide an estimate of the position of) a mobile station in response to a request from an LCS client is to obtain it from the RAN by which the mobile station is communicatively coupled to one or another operator network. The LCS client can request that the position estimate be given within a certain response time and so as to have a specified accuracy, which may be indicated by specifying a Quality of Service (QoS). During recent 3GPP TSG (Technical Specification Group) RAN WG2 (Working Group Two) and WG3 #39 meetings, it was approved that in all releases from Rel-99 onwards, UTRAN (UMTS Terrestrial Radio Access Network) will always return a location/position estimate, in response to a request for same, with the best achievable accuracy even if a requested accuracy indicated in the request is not achieved. Thus, a position estimate is to be returned to the LCS client even if it does not have the requested accuracy. It would be advantageous to provide to the LCS client not only the location estimate, but also an indication as to whether the location estimate has the requested accuracy, but the standard MLP (Mobile Location Protocol) interface between an LCS server and an LCS client does not allow this. However, an LCS server may not have all the information or capabilities in place needed to determine if a requested accuracy has been achieved for a location estimate made by a RAN.
Currently, an LCS client can specify a requested accuracy to an LCS server in terms of a number of e.g. meters, and in response to the request (after it having been forwarded by the LCS to the appropriate RAN), the LCS server receives a confidence area from the appropriate RAN (the RAN to which the mobile whose position is being estimated is coupled) in terms of a shape (typically the shape of a cell, e.g. a polygon or ellipsoid). In order to determine whether a location estimate has the specified accuracy, the LCS server would have to perform a calculation to determine if the confidence area (shape) is such as to provide the requested accuracy. An LCS server may not have all of the information necessary to make such a calculation; to do so, in general, the LCS server would have to have information regarding the shapes in use as different RAN cells. On the other hand, it is likely that a RAN would have such information, or, at the least, it is reasonable to implement upgrades to RAN equipment to be able to relate confidence shapes to requested accuracy or to otherwise determine whether a location estimate has a requested accuracy.